Sams Teach Yourself MCSE Windows NT Server 4 in 14 Days
(Publisher: Macmillan Computer Publishing)
Author(s): David Schaer, et al
ISBN: 0672311283
Publication Date: 12/15/97

However, structuring a domain geographically is not always advantageous or practical. Often, planning a domain based on function or department makes more sense. For example, your sales department might have its own domain, even if that sales department resides in several different geographic locations. This can be especially helpful if that department has its own management or special resources that it must administer itself.

Domains are abstract; your network is not. It is helpful when planning placement of domain controllers to think of your network in its physical terms. In other words, your network is probably a group of individual, well-connected LANs that are connected to each other over various types of slower WAN links. The domains on your network sit on top of this architecture, but often not neatly. It might be nice in some aspects if each of these well-connected LANs were a domain, but this is not always the most practical approach.

There can be only one PDC in a domain, which means that parts of a domain will be located on the other side of a slower WAN link from the PDC. Consider Figure 2.10.

In this figure, the PDC for the Chicago domain exists in Building One. Another section of the Chicago domain exists in Building Two. Buildings One and Two are connected by a 56kbps WAN link, which is much slower than the networking cable within the two LANs. The PDC and a BDC exist in Building One. Users in Building Two must log on across the WAN link. If many users are logging on, the WAN link becomes a bottleneck, slowing the logon process for the users in Building Two. Consider what would happen if we moved the BDC from Building One to Building Two, as shown in Figure 2.11.

Figure 2.10.  The Chicago domain exists over a WAN link.

Figure 2.11.  Moving the BDC in the Chicago domain to the other side of the WAN link.

Now, when users in Building Two log on to the domain, the process happens much more quickly because the BDC is now on their own LAN. It seems we have solved the problem of the WAN bottleneck with this move, but we have created another problem. Now, synchronization of the directory database between the PDC and the BDC must occur over the WAN link. Depending on the size of the database, the WAN link might be tied up for some time, making it much more difficult for users to access resources across the WAN link. Again, the WAN link has become a bottleneck. Unfortunately, there is no ideal solution to this problem. It becomes, instead, a matter of weighing the costs of logging on versus the costs of synchronization and making the best decision possible.

Understanding the effects on network traffic of placing BDCs locally or on the other side of a WAN link is important. Basically, having a BDC local means that synchronization traffic doesn’t occur over the WAN link, but logon traffic does. Moving the BDC to the other side of the WAN link reverses this. Logon traffic doesn’t occur over the WAN link, but synchronization traffic will.

2.6.6. Synchronization

When a user logs on to a domain, they do not request a specific controller to perform the logon validation. The first controller to respond to the request performs the logon validation. This could be either the PDC or any of the BDCs. The one that processes the request is often the one physically closest to the user.

All updates to the SAM database occur only at the PDC. This means that if you were sitting at the BDC and creating a new user, the new user would be entered into the SAM database at the PDC. The changes are then replicated to the BDCs via the NetLogon service. Communication between the PDC and BDCs within a domain is performed through the use of remote procedure calls (RPCs).

In order for backup domain controllers to validate user logons, the BDCs must have an up-to-date copy of the directory database, the master copy of which is stored on the primary domain controller. This is accomplished through synchronization. Synchronization is governed by the NetLogon service and occurs in the following manner.

At a predetermined interval called a pulse, the PDC checks its directory services database to see whether a change has occurred and sends a message to the BDCs that need the change. These BDCs then contact the PDC and download the information.

Two types of synchronization can occur: full synchronization, in which the entire directory services database is sent to a BDC, and partial synchronization, in which only changes in the database since the last synchronization are sent. This process can be fine-tuned using registry parameters found in HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\NetLogon\Parameters. These parameters are summarized in Table 2.4.